Subject: APPN arch.items 8264, 8265, 8266

From: Mike Evans <[email-masked]>
Date: Tue, 11 Jul 95 16:23:00 BST

Here are DCL's comments on the proposed architecture changes 8264, 8265 and
8266.  Sorry they are late, but since the updates are still being discussed
we thought we would submit them.

Mike Evans
Data Connection Ltd (DCL)
+44 181 366 1177

 ----------------------------------------------------------------------------

arch8264
 --------

No issues.

arch8265
 --------

We have a number of concerns with the proposed solution.

1)  The solution does not deal at all with the case when one of the
    duplicate nodes is specified by an End Node in origin or destination
    TG vectors.  For example, this would happen if the End Node had a
    connection network configured with the same name as a Network Node,
    and could result in the NN calculating an invalid route.

2)  If the duplicate VRN is caused by a local configuration change (ie.
    a DEFINE_CN command), TDUs with the duplicate VRN information are still
    sent into the network.

3)  The solution requires operator intervention to ultimately clear the
    problem.

Both 1 and 2 are relatively easy to fix (but add special case logic to
fairly critical codepaths).  3 is inherent in this approach to solving the
problem.

An alternative approach is to just treat the NN and VRN as separate 
resources
 - that is, create two node records in the network topology database, and use
the VRN indicator to distinguish between them.

This approach

 -  causes no network problems (since it is always clear which record a node
   descriptor or TG identifier refers to)

 -  doesn't require operator intervention

 -  handles the TG vector case as well.

We would also argue that it is more in keeping with the original intent of
the architecture - ie. the TG identifier control vector, which includes the
VRN indicator, _identifies_ the TG.

The only difficult aspect of implementing this solution is supporting the
6611 APPN MIB (which doesn't use node type as an index into the topology
table, so needs some code to handle the rare case when there are two record
with the same name but different types).

arch8266
 --------

It is not clear from the proposal which problem this proposal is attempting
to address.  We can see three possibilities.

1)   Centralising mode to COS mappings, so removing the burden of making 
sure
     all EN mode to COS mappings are consistent.  If so, then a simple
     START_NODE parameter would suffice.

2)   Handling ENs with incorrect mode to COS mappings.  If this is the 
problem
     then the solution to 1) is also sufficient (since by definition all the
     other ENs are consistent with the NN tables, so it doesn't matter who
     does the mapping).

3)   Handling a malicious or rogue EN (ie. a node trying to get better
     service for its sessions by specifying a higher priority COS than the
     session justifies).  If this is the problem, then the solution ought to
     be more secure than the one proposed, since the node can just send a
     different CP name (one that isn't restricted), or a different mode name
     (one that maps to a higher priority COS).  This lack of security is
     exactly the reason few implementations support the concept of
     unauthorised end nodes.

If the problem is 1 or 2, then I think inventing a new verb is currently
overkill.  If the problem is 3, then a more secure approach is required.